A Heuristic Approach to Program Inversion

There are many applications in which it is useful to compute the in­ verse of some program, that is, to find another program such that feeding the output of the original program as input to the new pro­ gram produces the original input. One such application is in program ming by specification: one would like to define a program to compute the square root of a number by the equation (√x) = x rather than supplying an actual iterative method of solving the equation. Another application of program inversion is in debugging. Given a program and an erroneous result, one would like to step backwards through the program to trace the source of the error. Yet a third application is in transforming the input domain of a program, such as the well known technique of multiplying polynomials by first performing an FFT; to get the result back into the original domain one needs to find an inverse transformation. Several methods have been suggested for performing such inver sion. Unfortunately they each suffer from several defects. McCarthy [3] suggests a generate and test approach; this will correctly find an inverse when it exists, but is computationally infeasible and can­ not determine whether the inverse is unique. Dijkstra [1] provides a technique for inverting programs symbolically, but requires that the programmer provide inductive assertions on conditional and loop statements. Korf [2] suggests another method that automatically pro­ vides these assertions, but recursions derived using his method a-e not guaranteed to be well founded. Several recent efforts [5,6] have gone into inverting Prolog; this differs from inverting other program­ ming languages in that Prolog is less procedural and more declarative. Methods for inverting procedural languages will thus also be useful for Prolog, but the reverse is not necessarily true. This paper suggests a method of providing these assertions au­ tomatically by heuristic methods. This method will not always find an inverse for a program, but when one is found it will always cor­ rectly terminate when the output of the original program is given as input. In addition, if an inverse is found it will be the case that the original function was one-to-one—in principle the inverse could itself be inverted to recover the original program. The method described here has been implemented as a MacLISP program. The program was able to derive the inverse of append (shown in detail below), a version of reverse as given in [2|, unary integer negation defined recursively using add1 and sub1, and sev­ eral other such small programs. The example of unary negation is especially interesting as a case where Korf's method is unable to find the inverse, because of the existence of two recursive clauses in its definition. 2 . Inversion o f M u l t i p l e Functions o f M u l t i p l e A rgumen ts The usual definition of the inverse of a function , is the function such that for all x in D. Unfor­ tunately this notation does not lend itself well to inversion of functions of more than one argument. For instance, in the LISP programming language it is true that Thus one intuitively thinks of car and cdr together as being the in­ verses of cons, but there is no one function that we can call cons" . On the other hand, we can express a relation between / and that does extend to multiple arguments and also to multiple functions: If we assume that , then by the above definition and the converse similarly holds. Thus we have